1. Field of the Invention
The present invention relates to the exchange of files and meta-information between system design tools and behavior modeling tools and/or simulators for the creation of Electronic Control Unit (ECU) software.
2. Description of the Background Art
Electronics in vehicles are gaining more and more significance. The number of microcontrollers in the automobile is consistently increasing. With the increasing number of electronic control units, the amount and complexity of functions engineers must design, code, test, and implement increases as well. Virtual ECU software emulates a real ECU in a simulation scenario. The ECU software can comprise components from the application and the basic software, and provides functionalities comparable to those of a real ECU or software code dedicated for a real ECU.
Today's ECU software comprises numerous software components (SWCs) with intensive interactions. In large ECU networks frequently installed in current vehicles, the number of SWCs can easily reach the thousands. Because the task of developing ECU components is usually shared by several departments or even different companies, not only the SWCs themselves have to be tested and validated, but also the interactions between them. The earlier in the development process that errors and inconsistencies are found, the quicker and cheaper it is to correct them.
In the creation of ECU software, files and meta-information are exchanged between several parties and in different context. For example the files and meta-information are exchanged between the system architect and the function developer, between a system design tool and a behavior modeling tool, between different projects in the same or different system design tools, between different projects in the same or different behavior modeling tools. The files and information may regard ECU software created according to the AUTOSAR methodology or not according to this methodology and may regard a real ECU or a virtual ECU. FIG. 1 illustrates an example how, according to the AUTOSAR methodology, architecture or AUTOSAR authoring tools 1 used by the system architect and a behavior modeling tool 2 work together by exchanging standardized AUTOSAR ARXML files. A key element in this is the Software Component Template, which describes the content of AUTOSAR software components. The software architect decomposes the entire software into a number of software components (SWC) 3 and makes sure that the software components communicate with one another through compatible interfaces. The software architect typically exchanges ARXML files with multiple function/software developers who use the behaviour modeling tool 2 to provide the implementation of individual software components. Typically, the development of software components is an iterative process in which ARXML files, source code, and variable description (A2L) files are exchanged multiple times between the system architecture tool 1 and the behaviour modeling tool 2 to accommodate changes.
Thus, many files are generated during software creation. These files, however, must be appropriately managed. The ASAM AE CC (container catalog) was thus introduced to make this management easier, which is a generic approach for exchange of engineering data and its configuration. It describes the meta data of a set of objects (e.g. files) in an exchange container which is exchanged between repositories or tools. In other words, this standard defines a meta-model, which is used to organize the file exchange among those involved in an ECU development project. The files to be exchanged and some additional information are written in the form of an XML file. The container catalog facilitates the exchange of relevant data by predefining a fixed format according to which the users collect and pass on the appropriate files and meta-data.
Examples of types of files to be exchanged are the exchange formats defined by the AUTOSAR (AUTomotive Open System ARchitecture) standard, in the form of ARXML files (AUTOSAR XML), with which AUTOSAR-related data are transferred between development tools. Apart from ARXML files, the development of AUTOSAR-compliant software also involves numerous other file types which must be exchanged between the software architect, component developer, software integrator, and tester. Thus, the behavior modeling tool generates code files for implementing components that are used, for example, for component and software integration tests in the development process. In addition, documentation files for describing component design can be exchanged, just like A2L files for calibration and measurement, where this is still not sufficiently enabled by the AUTOSAR standard. These files and the AUTOSAR-standardized ARXML format require special handling in carrying out round trips, as typically occur during the development of AUTOSAR-compliant application software.
The creation of the container is problematic, particularly in iterative processes of software creation in which files pass repeatedly back and forth between the different users (system architect and function developer).
After each modification, all relevant files must be searched together and the most recent versions stored in the container. This, however, is time-consuming and error-prone for the function developer or system architect to describe consistently all function information and meta-data after code generation, or to collect and store them in the ASAM container. The developer must retain an overview over a vast amount of data and files and it must be assured that files or data are not inadvertently overwritten. Additional difficulties arise, for example, due to name modifications and obsolete files.
Thus, there is a problem when a container is typically transferred by a second user to a first user, and if the first user has an older version, he has difficulty determining which of the many files were modified or updated by the second user and which updates he should adopt.